Jenkins Kata 4: Integrate Git with Jenkins
Learn about installing and configuring the Gogs-Webhook plugin and configure and test the build trigger.
CI is the automation of a software delivery process. When integrated with an SCM system, Jenkins can be configured to run a job (or set of jobs) automatically each time code changes are pushed to a source code repository. When a build is run with each code update, bugs can be discovered and fixed immediately. This is much more efficient than allowing many problems from many code updates to clog the development lifecycle.
This kata will demonstrate how to configure a Git server to trigger Jenkins jobs when commits are pushed to the Git server.
Step 1: Install the Gogs webhook plugin#
The following are the steps to install the Gogs-Webhook plugin:
- Click Jenkins at the top left.
- Click “Manage Jenkins.”
- Click “Manage Plugins.”
- Click the “Available plugins” tab.
- Type “Gogs” into the filter field.
- Check the box for the “Gogs” plugin.
- Click “Install without restart.”
- Wait for the installation to complete, then click “Go back to the top page.”
Jenkins can be extended by installing plugins. Jenkins plugins are written in Java, as is the core Jenkins platform. Plugins add packaged, purpose-built functionality to Jenkins. Typical plugins add features to Jenkins and provide integration options between Jenkins and other systems. This step installs the Gogs plugin to Jenkins.
The Gogs plugin was written by the maintainer of the open-source Gogs Git server, specifically to integrate Gogs with Jenkins. A webhook is a generic term for an integration point between a Git server and another system. The Gogs plugin is designed to provide Jenkins with a way to receive build trigger messages from a Gogs server. The next step in this process is to configure a build trigger in the “web-storelist” job.
Step 2: Configure a build trigger#
- Click the “web-storelist” job.
- Click “Configure.”
- Click the “Build Triggers” tab.
- Check “GitHub hook trigger for GITScm polling.”
- Click “Save.”
Jenkins jobs can be executed by several means. Previous steps have used a manual trigger: the “Build Now” button in the Jenkins user interface. Automated processes, however, need a way to trigger a build through an HTTP POST request, sent directly to Jenkins from another system.
The “GitHub hook trigger” is a webhook trigger. GitHub is a hosted Git server used by open-source software developers and private companies for SCM services. The Gogs server used in this course, as well as many other Git servers, support GitHub-style webhooks.
This setting tells Jenkins to expect a webhook call to trigger the “web-storelist” job. While manual triggers will continue to work, there’s now the additional option to trigger a build from an event outside Jenkins. The next step will configure Gogs to execute the webhook every time a commit is pushed to the web-storelist repository hosted in Gogs.
Step 3: Configure the webhook in Gogs#
- Log in to Gogs as Cody (username: “cody.coder” and password: “katas”).
- Select the “web-storelist” repository from “My Repositories.”
- Click “Settings.”
- Click “Webhooks.”
- Click “Add a new webhook.”
- Enter the following in the “Payload URL” field: “https://ed-6091404232622080.educative.run//gogs-webhook/?job=web-storelist”
- Click “Add Webhook.”
Step 4: Test the trigger#
- Click the pencil icon in the webhook.
- Scroll down and click “Test Delivery.”
Jenkins has been configured to listen for webhook requests to the “web-storelist” job. Gogs must then be configured to send that request to Jenkins. This step configures the webhook in the Gogs server.
The Gogs webhook can be configured to trigger on many events within Gogs, including branch creation, forking, and others (we can view the list by selecting “Let me choose what I need” when creating a new webhook in Gogs). The configuration set in this step only triggers on the git push event. Each time a commit is pushed to the main branch of the “web-storelist” repository, Gogs will send the webhook trigger to Jenkins, which will execute the web-storelist job. The last action in this step was a test of the trigger, which manually executes the webhook call. Jenkins then shows that a new build was indeed triggered, adding a new build to the build history.
Step 5: Trigger a job with a push#
- Switch to a terminal window
- Copy an additional item from the Main List to the Next Visit list.
- Save the changes.
- Switch to the terminal window.
- Return to Jenkins.
- View “Build History.”
This step demonstrates a real-world CI automation. A change was made to the storelist.htm file, then committed to the local repository and pushed to Gogs. The Gogs webhook executed, sending a request to Jenkins, which then executed the “web-storelist” job. Gogs and Jenkins are now set to pull and build the “web-storelist” project every time a new code contribution is made by any developer.
We can view the workspace for the “web-storelist” Jenkins project, open the storelist.htm file, and see the changes that triggered this build.
Jenkins Kata 3: Automated Testing
Jenkins Kata 5: Docker Container Build Step